Chap.2 リファクタリングの原則

二つの帽子

機能追加とリファクタリングを区別する

ケント・ベックによる（XP本？）

頻繁に二つの帽子をかぶり直す

例：機能追加したい

リファクタリングの帽子をかぶってコードの構造をよくする

帽子を変えて機能追加

動くコードになったら帽子を変えてリファクタリング

（TDDのRed-Green-Refactoringに通じそう）

リファクタリングを行う理由

ソフトウェアの設計を改善する

ソフトウェアを理解しやすくする

ソースコードはコンピュータに指示する（振る舞いの観点）

指示を変更するためにコードを読む将来の開発者がいる（構造の観点）

この利用者の存在は、軽視されがちですが、実際には最も重要なのです。(Kindle の位置No.1424-1425)

バグの発見を助ける

プログラミングを速める

すぐれた設計を前もって完了しておくことは非常に難しいので、すばやく機能を追加し続けるには、リファクタリングが不可欠 (Kindle の位置No.1476)

リファクタリングとアーキテクチャ、そしてYagni

将来の変更に対して、後でリファクタリングするのは難しいかどうか、見積もってみるとよいでしょう。

（前提として、この本で紹介するリファクタリングテクニック1つ1つの適用は簡単）

後でリファクタリングするほうが難しいと感じられるときには、そこで初めて柔軟性の仕組みの導入を考えます。(Kindle の位置No.1868-1870)

（最終責任地点のような考え方？）

リファクタリングとソフトウェア開発プロセス

XP

リファクタリングとパフォーマンス

リファクタリングの起源

自動化されたリファクタリング

IntelliJ IDEAやEclipseは「ツールがリファクタリングを自動的に行ってくれます」

最も原始的（プリミティブ）な方法は検索・置換

適切にリファクタリングを行うには、ツールはプログラムのテキストではなく、構文木を操作すべきです。(Kindle の位置No.2060-2061)